WAS-DS by KU?

“El trágico caso del infierno de las DLL”

La idea original era liberar en un servidor de Terminal Center (CITRIX) todas las aplicaciones corporativas de la compañía. Se revisaron las aplicaciones como actualmente están operando, y se detecto que estas tenían que ser modificadas. Esto debido a que había una concurrencia significativa de archivos. Mayormente a la hora de imprimir. ¿Porque? Básicamente porque la forma de impresión de los sistemas se base en abrir un archivo excel o word (según sea el caso), modificar el documento con los datos requeridos, salvar el documento como y mandarlo a impresión. El problema es que cada quien los hacia como se le antojaba, por lo que se decidió hacer un proceso estándar de impresión, y de ahí cada quien modificaría sus aplicaciones. Se liberaría y asunto terminado. Tan fácil que es la cosa.
Así, cada uno de los responsables de un equipo, se dio la tarea de modificar sus respectivas aplicaciones, en lo personal me tocaron 7 , todas en visual Basic 5 , tarea sencilla. Pasamos por alto los por menores de análisis, programación, etc, etc. Y nos pasamos a lo bonito del asunto.
Total que todos los responsables terminaron sus respectivas aplicaciones, yo termine mis aplicaciones antes que nadie, esto es debido a que solo estaba dedicado a ello, y me valí de 3 recursos externos. Liberamos en el ambiente CITRIX, hice las pruebas respectivas de liberación, y chan, chan, todo perfecto. La mayoría fue terminando después, y algunos hicieron sus pruebas unitarias en servidores de Desarrollo.
Se entregaron los instaladores a Calidad, y ahora si, empieza el proceso de pruebas de calidad
Oh sorpresa que nos llevamos algunos. Iniciaron los problemas, instaladores no tan actualizados, Eso fue lo menos critico, empezó el tétrico y fantasioso infierno de las DLL. Antes que nada, déjenme decirles que las aplicaciones que se iban a liberar son de dulce, de chile y de manteca. Visual 3, 4, 5 y 6.
Primera zancadilla, algunos tenían una versión de RDO 1.0 del año del 95 otros, más actualizados (¿???) Tenían la del 97. Y empieza la tronadera de aplicaciones. En realidad, eso fue lo más sencillo, debido a que éramos pocos los que usábamos esta versión, así que se decidió hacerla en la mas viejita por cuestiones de funcionalidad.
La segunda zancadilla sucedió cuando repentinamente, se instalo la aplicación de ultima persona que entrego sus aplicaciones. El unísono las demás aplicaciones empezaron a tronar (nos dimos cuenta 5 minutos después porque varios estábamos haciendo pruebas). El error en pantalla decía “Error 50003”.
Quien este familiarizado con ese error, sabrá que es con una de las DLL mas comunes de windows, la OLEAUT32.dll (también ocurre con la de common controls pero este no es el caso)
Y nos percatamos que ese instalador ocupaba una versión mucho más nueva, sospechamos por ser la única aplicación que hecha en visual 6. y empiezan las discusiones, y empiezan los dimes y diretes , y empieza a armarse la rebambaramba.
Todavía estamos en periodo de solucionar este problema, y otros más. Todo gracias a maldito DLL’s HELL
Tal vez fuimos ilusos al pensar que se podían liberar todas las aplicaciones en una misma maquina o ambiente de pruebas, tal vez fuimos descuidados al no tener un ambiente unitario para instaladores, tal vez nos falta homogeneizar las aplicaciones y hacerlas en una mismo ambiente. Pero esos, son problemas internos que no les voy a contar. Ahora alzamos los ojos al cielo, soñando nuestro más preciado anhelo, estamos viendo lejanamente nuestro futuro en una sola versión de Visual. Todo dirigido a Punto NET.
Pero, aun así, no creo que nos evitemos esa maldita transición de cambio de versiones. De hecho, me pude percatar que las aplicaciones hechas en el NET Framework 1.0 no pueden abrirse en el mas reciente, en la versión 1.1.
En conclusión, somos unos ilusos al pensar que las cosas son tan fáciles como las prometieron.

“I love Microsoft FrameWork”

He terminado por fin las 5 semanas de cursos intensivos en el Framework de Microsoft. Terminas extenuado, después de un cocowash, sientes que llevas la camiseta de microsoft tatuada en tu pecho. Y como no va a ser cierto, si escuchaste a diario durante 25 días de las maravillas que según esto Microsoft ofrece. Que si los Webservices, que si remoting, que si la serializacion, que si reflection, que si los patrones de diseño, que si C sharp, que si los aplicattion blocks , que si los enterprices templetes.
Los debates casi diarios de si usar C sharp o Vb.Net no se hacían esperar, voy a extrañar el goleo (entiéndase por goleo a establecer un tanto (gol) por cada vez que se encontraba una ventaja entre ellos), según recuerdo el marcador final fue a favor de C#, las eternas comparaciones entre la tecnología Java y la tecnología Microsot nos hacen concluir que Microsoft como siempre se pirateo los conceptos de las demás tecnologías.
Le copio a los JSP, le copio a Java virtual Machine, le Copio a los JavaBean, Le copio a los Servlets, el garbage Collector vamos hasta el C# es una copia del lenguaje Java, y nos podemos pasar toda la tarde citando conceptos pirateados, pero en fin, fuere cual fuere el resultado, el efecto es el mismo. Una herramienta poderosa para la construcción de aplicaciones de todo tipo. Y eso es, lo que en realidad importa.
Y eso es, en realidad de lo que se trato esta capacitación, del conocimiento de las herramientas expuestas por Microsoft, que nos pueden servir a nosotros como desarrolladores, para efectuar soluciones competentes y eficaces a problemas reales.
He dado un paso mas, he aprendido a reconocer los nuevos tecnicismos, he aprendido a construir aplicaciones en base a ellos, y he aprendido a que este universo de tecnologías es inmenso, y que tan solo esto es una pequeña parte de el.
Y eso, que no les platique acerca del Boot Camp para Arquitectos de Software al cual también asistí.
Pero eso, después se los comento.

10/Marzo/2003 "Buenas criticas a malos proyectos"

Es muy fácil para el ser humano, el llegar a criticar a los demás, nada mas por el simple gusto de ser, tal cual vieja chilmolera, acusas al contrario, criticas al por mayor y desmeritas a las demás personas. Tal vez en el vecindario esta llegara a ser divertido, peligroso si, pero es una manera no tan mala de pasar el rato. Ya en el lugar de trabajo, es cosa diferente, porque ya involucra envidias de por medio, zancadillas, mala leche, y alguna que otra practica malsana de competencia.
Pero que pasa cuando, ellos exigen ser criticados, piden a gritos que alguien critique su trabajo, están ansiosos de que las demás personas les digan sus fallas. Claro, realmente es difícil que alguien le pida a los demás que salvajemente destruyan lo que tanto esfuerzo le costo construir. Mas bien lo que me refiero, es el sentido de que alguien lleva un proyecto tan mal planeado, tan mal analizado, tan mal especificado, tan mal diseñado, tan mal documentado, tan mal ejecutado, tan mal tan mal, que uno no se puede quedar callado y evitar las criticas. Claro en un inicio sutilmente le haces ver su error, pero cuando se suben su burro, no hay quien los baje.
No quiero quemar gente, pero el hecho esta en que si uno desde el principio no entiende los requerimientos del usuario, no entiende el contexto del requerimiento, y no se busca entender de las necesidades especificas del problema. Queriendo alardear, queriendo entregar algo mas de lo que se te pidió, inclusive queriéndose poner el papel de Innovador, se puede llegar a consecuencias catastróficas para un proyecto en sí.

Por eso es recomendable, entender el problema, y resolver de lleno ese requerimiento, y ya después, uno puede ponerle el granito de arena, y empezar a pensar en los “y que tal si le ponemos”. Porque finalmente, la solución haría todo, menos, precisamente solucionar el problema inicial.

Viernes 6/Diciembre/2002 “Es difícil aprender, si tienes trabajo que hacer”
Durante toda una semana, me ocupe de abandonar mi trabajo, de dedicarme a aprender cosas nuevas, de enfocar el conocimiento hacia otras partes de la programación.
Siento como que de nuevo estoy empezando a evolucionar, leo un manual, no le entiendo, entro al curso, la explicación en frustrante y un poco tediosa, nos muestran el demo, y las cosas empiezan a cambiar, practicamos con el demos, y las cosas se vuelven un poco mejor, de nuevo el siguiente capitulo, casi como rezándolo, entre escucho la platica, y sigilosamente abro el solitario, y empiezo a jugar sin levantar sospechas. De nuevo, un ejercicio, y mi atención esta de nueva enfocada al curso. Interesante, es mucho mejor hacer las cosas practicas. Sigo navegando en los menús contextuales de la herramienta. Empieza el workshop, en una pagina viene el ejercicio que tenemos que hacer nosotros solos, que no es mas que aplicar lo que hemos vistos en el capitulo. Zaz, la cosa mas maravillosa, fácil , fácil, como es posible que no se para que sirve, pero se como hacerlo que haga su trabajo. Termine antes que los demás, por lo tanto, he de terminar mi solitario, que en realidad no es el solitario, es el freecel, pero a mi me gusta llamarlo así. No me han de creer, pero hasta antes del curso no sabia jugarlo, ni siquiera el verdadero solitario, pero a partir del curso, me hice adicto. Digo, estoy en las instalaciones de la empresa que da el curso, no tengo correo, no tengo email, no tengo presión de los usuarios, no tengo el Query analyzer, ni el visual, ni el Visio, ni ningún software que tenga que ver con mi trabajo actual, que puedo hacer el los breaks y horas de comidas.
El curso estuvo interesante, y aprendí los la manera eficaz de hacer extracción y transformaciones de información para un DataWarehouse, con una herramienta por supuesto, del proveedor de esa infraestructura. Cognos a saber, y su programa desicionStream. Algo nuevo para mí, pero que será mi próximo futuro, ya que pronto cambiare de área de desarrollo.
Un curso pesado, pero que me hizo olvidar por el momento que tengo mucho que aprender, y muchas cosas en el trabajo que hacer , que me impiden iniciar el aprendizaje.
En fin, he de regresar la proxima semana, a terminar todos mis pendientes.

Viernes 29/Noviembre/2002 “Solución de problemas internos”

Una de las peores cosas de estar enfermo y tener que trabajar, es precisamente eso. Estar enfermo y tener que venir a trabajar. Casi el 80% de la tarea realizadas por un desarrollador de sistemas esta ligada de una u otra manera a utilizar la materia encefálica. La poca materia encefálica con la que el ser humano ocupa. Es decir, que la mayor parte del tiempo las personas de desarrollo de sistemas, están ideando nuevas alternativas de solución, resolviendo viejas problemas causados por las alternativas de solución y buscando la solución ideal para que todas las soluciones realizadas y por realizar le sirvan al medio ambiente en que trabaja el usuario.
Y todo tiene que salir de una sola parte, asi es, del cerebro.
¿Pero como puede uno siquiera poner en orden alguna idea, si el cerebro esta el 90 % preocupado por resolver los problemas internos del cuerpo que le toco controlar? Que si la temperatura corporal esta subiendo, que si los residuos nasales están siendo evacuados mas de la cuenta, que si un taladro gigante esta arremetiendo contra las sienes. Etc, etc. ¿Y todavía quieren que decida de manera eficaz, si utilizar cancelaciones físicas o lógicas de un pago prerregistrado o si los tiempos especificados para una tarea están mal prorrateados de acuerdo a las habilidades del externo y el conocimiento de la base de datos actual?
Y lo peor, todavía tienes que seguir contestando las llamadas de tus compañeros de equipo que se encuentran en junta.
Mi pobre cerebro va a estallar, ya no sabe que hacer, si solucionar los problemas internos luchando contra los enigmas de la gripa o encontrar la manera de ocupar el 0.23% de sus recursos libres para terminar el análisis de requerimientos.

¿Cree usted que sea justo?

No. de veces que sonó el teléfono en lo mis compañeros se fueron de junta: 9
No. De veces que era una llamada para mí: 1
No. De veces que era el mismo usuario preguntando por la misma persona: 4
No. De pañuelos desechables ocupados en ese lapso: 5
No. De hojas de especificación terminadas en ese tiempo: 1 ½
No. De estornudos en el mismo tiempo: 8

Viernes 22/Noviembre/2002 “Estar aunque no tenga que estar”

¿Pasas inexistente en tu lugar de trabajo?

Algunas veces, me pregunto si soy parte activa del equipo en el que estoy. Cuando mis otros dos compañeros se van, todo parece un caos. Millones de llamadas entran a sus teléfonos, las mismas veces tengo que disculparlos con los usuarios, pocas menos pregunto si puedo ayudarlos, y muchas mas no tengo oportunidad de hacerlo. Entonces me pregunto. ¿Acaso no puedo resolver los mismo problemas que ellos pueden resolver?
Tal vez no. Dado que somos del mismo equipo, pero son procesos en los cuales no tengo nada que hacer, no tengo conocimientos o pocas personas saben que existen.
Mi universo solo son dos procesos importantes, sí, pero no cruciales para la operación diaria de la compañía. En pocas palabras, puedo faltar todo un mes, y mi ayuda no seria requerida.
Tal vez, por eso me pude ir a un curso de DataWarehouse por toda una semana y no aconteció nada que me impidiera continuar en él.
Algunas veces echándome ánimos pienso, es que hago tan bien las cosas que no necesito estar corrigiendo nada en los servidores de operación. O más bien, acostumbre a los usuarios a que no necesitan hablarme a mí para resolver sus problemas, para eso están las personas que se hacen cargo de operación, “la famosa continuidad operativa”. O tal vez , los usuarios usen poco los sistemas, o prefieren no reportar los errores.
En fin, el hecho, es que cuando decido, llegar un poco tarde o tomarme un día de mas de vacaciones, ahí está mi teléfono suene y suene, todo mundo me anda buscando, solo yo puedo resolver ese problema. ¿Pues no que no era importante? Sospecho que alguien me vigila, y que los usuarios reportan los errores cuando ven que no estoy sabiendo que debería estar.
Aquí hay un complot en contra mía.

Viernes 15/Noviembre/2002 “Esquemas pisoteados”

¿Raro no? Este es el primer día que escribo sobre mi vida en la oficina, y tenia en mente explicarles lo mucho que hacen sufrir los usuarios a un ingeniero en sistemas, lo mal que se portan, lo exigentes, la falta de compresión por parte de ellos, el menosprecio, el día y la noche intensas de trabajo. Y todo lo difícil que es sobrevivir en esta carrera.
¿Y que paso?
Todo lo contrario.
En la mañana, uno de los usuarios principales del modulo en el cual soy responsable, me invito los tacos, puesto que teníamos una junta a las 12 para revisar los puntos que se iban a entregar en la ultima liberación del sistema, antes de la famosa y esperadísima “entrega total del modulo”. Para camuflagear la “transacción”, simulamos una junta de improviso. En donde junto con el responsable anterior del modulo, el líder de usuario, un responsable y yo, nos dimos a la tarea de dar “una revisión preliminar”. Pero creanlo o no, esta reunión extraoficial e informal ayudo a despejar una de las dudas que habían surgido en la anterior liberación.
La sala que apartamos estaba ocupada, puesto que el gerente estaba en una presentación, y como es de saberse “hay prioridades”, la secre del gerente nos iba a apartar otra, pero nos la gano otra persona. El gustosamente nos cedió el lugar, ¿No que los de sistemas éramos inaccesibles y sin cortesía?
Ya después en la junta de revisión, junto con el departamento de calidad, revisamos cada uno de los puntos. A lo cual, el usuario líder (el invito los tacos), acepto nuestras propuestas, acepto las excepciones, y de buena gana, acepto las tareas que no iban a entrar en la ultima liberación.
¿Y luego? No que los usuarios eran quisquillosos y siempre a regañadientes se hacia lo que ellos querían. Será acaso pura fama.
En la tarde mi novia cumplía años, y le llevaron pastel a la oficina. En donde todos animosamente socializamos. Algunos mas que otros. ¿No que los de sistemas no tenían vida social?
Son las 6:30 y ya me voy. Puesto que hoy es viernes. Y por supuesto que mañana no vengo.
¿no que los ingenieros en sistemas trabajaban hasta tarde, sábados y domingos y carecían del tiempo para tener vida?
Los tiempos han cambiado.
Espero que con esto que les conté, piensen que soy jefe o que soy alguien que no trabaja en todo el día. De que hay días, hay días.
Pero hoy, se rompieron todos los esquemas. Tal vez por eso decidí iniciar esta nueva aventura.
El lunes...Las cosas volverán a ser igual.